I'd suggest calling it retErr or so, to distinguish between errors.

Err is what I usually use.

So, what would happen if net.Listen fails? Please be careful.

I was wrong here (except that you rewriting the error).

No need to metion the defer part will run after func returns. so if any error happens in closing, the retErr will be refilled. the question is: is it important to you to handle this kind of errors in the caller function?

There is also another problem: if the func returns because of another error, and at the same time, the close also fails, the former error will be lost! while the closing error is bound (in my opinion) I believe the original error is more significant ... tell me what to do?

I decided to ignore closing error...

same here

There are several changes of this form, and while Close can fail very few Go programs handle this case successfully all the time and you would need to write the same boilerplate for each case:

defer func() {
  if Err != nil {
    Err = foo.Close()
  }
}()

Aside from adding a bunch of boilerplate to lots of functions, the second question is when will close(2) fail and does it make sense to deal with this? Most close failures are actually when the filesystem had an error writing to disk, but this mechanism in Linux is unpredictable and ultimately there's not much to do if that's why close(2) failed (very often the failure happens during a later fsync(2)). Most other close(2) failures don't apply to most Go programs. Not to mention that the worst thing that happens is that we keep a file descriptor open in a program which takes about 100ms to run -- and we can't do anything about it anyway because the semantics of close(2) are that you cannot safely attempt to re-close a file after calling close(2).

We can do it, but I don't see the benefit and if the only reason for this change is to make a CI lint happy, we should turn off the CI lint IMHO.

Yeah, the alternative that is not too much fuss and makes static checkers happy is same as in (void)write(); in C, i.e.

defer func() {
  _ := foo.Close()
}

Thanks for your expressive description. As a boilerplate, I may suggest this one:

defer func() {
  if err = foo.Close(); err != nil && retErr != nil {
    retErr = err
  }
}()

because we should try to close() anyways. but its much more than its needed (I think), and as @kolyshkin said, I'll try to simply ignore the closing error across my MR

This change is not inline with what the commit message says. Please split your commits carefully.

OK it seems that in this case a single channel is enough, there is no need to have two.

You did't have to change any of this.

IOW this can stay err -- the only place to use retErr is the defer.

same here

same here

same here

IOW this could be simple

_, err := io.Copy(os.Stdout, c)
chan <- err

and the code that's receiving this will check for nil